As the use of portable electronic devices with integrated microprocessors becomes more widespread, and the technology pertaining to them advances, the amount and variety of information contained in such devices continues to grow, thereby expanding the potential applications for them. In this regard, one particularly interesting application constitutes the use of these devices, such as smart cards, PDAs, mobile telephones, portable devices which contain a Java Virtual machine, etc., as hosts for services in a distributed computing system. In this context, the device stores one or more application programs, e.g., applets in the Java programming language. Each such application has a corresponding client program that communicates with the application stored on the device. Typically, the client program might be stored in a terminal in which the device is inserted, or with which the device otherwise communicates. The client programs and device applications exchange messages with one another, and thereby permit a user at the terminal to employ the services provided by the applications on the device.
Typically, in a distributed computing environment, the client and server portions of an application communicate with one another by means of a predefined set of semantics. One example of such a semantic is a procedure call. Another example of a semantic, in an object-oriented programming environment, is a remote method invocation (RMI). In the context of this latter semantic, the functions, or methods, that can be performed by the server program are published, e.g. through an application programming interface, and the client program interacts with the server program by invoking these methods, and providing any parameters that are associated with the invocation. The server program performs the operation that was requested by the client, and returns a result. This protocol facilitates the development of new client programs, since the program developer need only be aware of the published methods for the server program, and write appropriate calls to invoke those methods.
When using a portable electronic device as a host for distributed services, the device may be required to communicate with the client by means of a specific protocol. In the context of a smart card, for instance, the card and the terminal must communicate with one another in accordance with the standards that are applicable to smart cards. Specifically, ISO/IEC 7816-4 specifies that the card and the terminal communicate with a message structure known as the application protocol data unit (APDU). Messages are exchanged as a command and response pair. In the development of applications for the smart card environment, therefore, the program developer was required to be familiar with this message structure, and incorporate code into the program which conforms to the applicable protocol. For instance, the software on the smart card had to include program code which operated to decode command APDUs and encode response APDUs. On the terminal side of the application, the software had to include program code which performed the corresponding inverse operations. Similarly, other types of portable devices may have specific requirements regarding message structure. Consequently, the development of application programs that were designed to operate on such devices was quite complex.
To alleviate this burden in the development of applications for devices with specific communication requirements, semantic frameworks have been proposed. For instance, an RMI framework for smart cards enables programmers to deal with the card applications at the level of method invocations, and not concern themselves with the APDU message passing mechanism. In essence, this result is accomplished by the use of a client proxy at the terminal side of the system. When the client program invokes a method, this invocation is presented to the proxy. The proxy converts the method into the appropriate APDU message, which is then transmitted to the card. At the card, a skeleton program performs the inverse function of the proxy, and transforms the received APDU messages back into the appropriate method calls. These calls are then presented to the on-card application, which returns a corresponding result.
To facilitate the generation of the client proxy and the card skeleton in the Java programming language developed by Sun Microsystems, a programming tool such as a Stub Generator can be made available to programmers. In the context of smart cards, for example, a Stub Generator which is adapted to a subset of Java that is executed on a smart card, known as Java Card, can be employed. In the development of a service that is to be available from a smart card, the programmer develops the implementation of that service, namely, the actual steps of the program that perform the service, as well as an interface which defines entry points of the application on the card, i.e. the list of methods that are available from the implementation. The Stub Generator tool that is adapted to Java Card then generates the client proxy and the card skeleton from the definitions provided via the interface, to provide appropriate conversions between the published methods and corresponding APDU messages. The card application, which consists of the implementation code, the interface and the card skeleton, is then installed on the card, and client programs are developed which communicate with the client proxy to invoke the methods available through the card service.
The use of the client proxy and card skeleton to facilitate the transport level communications between the terminal and the card provides a number of advantages. First, the card applications can be written in a known language, e.g. the Java programming language. The proxy and skeleton make the APDU protocol transparent to the operation of the program. Consequently, the program developer is not required to have any knowledge of this protocol. As a result, a portable service provider such as a smart card, a PDA, etc., can be readily integrated into a distributed computing model, rather than having to be treated as a special device.
One limitation that has been heretofore associated with the use of the proxy and skeleton to provide a layer of abstraction between the card service application and the APDU messaging protocol is the fact that it restricts the flexibility of the application once the skeleton-proxy pair has been generated. More particularly, while the co-development of the proxy and the skeleton, for example by means of the Stub Generator, ensures compatibility between them, such compatibility only exists as long as they remain static. However, if the application is subject to ongoing development, enhanced or upgraded versions of a card application may include additional methods that can be invoked by clients, resulting in the publication of a new interface. Consequently, a new skeleton must be generated, to decode APDU messages that relate to the newly-available methods that can be invoked. However, the new skeleton may not be compatible with client proxies that were developed for earlier versions of the application. For instance, the newly developed skeleton may provide a mapping between APDU messages and invokable methods which is different from that of the original proxy and skeleton. As a result, a new proxy will have to be provided, to communicate with this new skeleton. The on-card application will not be able to be used at terminals which employ the original proxy, and vice versa.
As one solution to this type of problem, it is possible to employ an approach in which the generation of the proxy and skeleton must always occur together, to ensure compatibility between them. However, this approach is not practical in an environment where the card application continues to evolve. Each time new functionality is added to the card service, a new proxy-skeleton pair would have to be generated, and the new proxy would have to be deployed to all of the existing terminals which are designed to work with the application. Thus, even if the client programs are not changed, the proxies must still be updated at each of these locations.
As an alternative solution, it is possible to establish a universal mapping between a particular APDU message and a method that is to be invoked with that message. Again, however, such a solution can prove to be impractical. First, it is quite costly in the sense that the length of each individual APDU message would have to be relatively long, on the order of 4-8 bytes, to provide a sufficient number of unique messages that could accommodate all possible methods. Furthermore, it would require a common agreement among all developers of application programs for smart cards, and would have to be language independent. Finally, because of the potentially large number of methods, a large amount of memory would be required in the card to store the mapping between such methods and their corresponding APDU messages.